Security For Network-Connected Vehicles and Other Network-Connected Processing Environments

ABSTRACT

A method and apparatus provide security for a network-connected vehicle (or other networked environment) in which a predefined set of permitted operations relating to protected resources can be initiated remotely from elsewhere in the network, while security is maintained for the protected resources (for example, an engine performance optimisation control unit or air conditioning control unit within a vehicle) by preventing remote initiation of any other operations on a data processing unit which is connected to the protected resources. One of a pair of gateway components runs on each of two data processing units within the vehicle (or other environment), the first processing unit being connected to the vehicle&#39;s device control units and the second processing unit being connected to the external network. The gateway components control the types of communications which can be passed from the network-connected side to the first processing unit such that only permitted operations can be requested and no unauthorised operations can be initiated remotely.

FIELD OF INVENTION

The present invention relates to provision of security for controlsystems of vehicles which have access to computer networks, such asvehicles having a mobile connection to the Internet. The invention alsohas application for improving security for network-connected dataprocessing resources within a home or office environment and any otherprocessing environment which has critical resources which must beprotected from unauthorised access.

BACKGROUND OF THE INVENTION

It is known in the art to interconnect a vehicle's internal devicecontrol units via field buses such as CAN, J1850, VAN, and others. Thesedevice control units are typically inaccessible from outside thevehicle. Protection from unauthorised access from outside is essentialto ensure safe operation, since the device control units directly accesssafety-sensitive hardware such as the vehicle braking system.

Recent attention has been given to the idea of vehicles being connectedvia a mobile link to networks such as the Internet, to enable driversand passengers to access traffic and navigation information for example,and to support emergency and breakdown calls from the vehicle. In thepast, these applications have not needed to interact with the vehicle'sinternal network which interconnects the electronic control units. Atypical protocol for these communication functions is the upcomingGlobal Automotive Telematic Standard (GATS).

A serious security problem arises as soon as Internet access, or othernetwork access, is desired to enable operations relating to thevehicle's internal electronic device control units to be initiated byusers or programs elsewhere in the network. For example, there may berequirements to allow an authorised breakdown service company or thevehicle manufacturer to be able to request specific operational data todiagnose problems and then to remotely initiate corrective operations.If remote access to the vehicle's internal buses is possible, then thereis a risk of hackers interfering with the vehicle's internalcommunications, and changing system parameters or triggering operationswhich could lead to control unit faults. There is also a risk of hackersobtaining confidential information from the internal control units.There is currently no known solution to these problems which applies tovehicles.

Additionally, if software can be downloaded via the network links, thereis a potential for such downloaded software to monopolize the availablehardware resources or the vehicle's internal communication bus. Thiscould impact the performance of critical operations.

Similar problems arise in non-vehicle environments, whenever there is aneed to achieve both the protection of resources from unauthorisedoperations and the ability to invoke certain operations relating to theprotected resources from elsewhere in a network.

SUMMARY OF INVENTION

The present invention provides network access to and from a vehicleincluding access for applications which need to communicate with thevehicle's internal device control units, implementing this by using atleast two physically separate processing units within the vehicle. Afirst processing unit handles operations which affect the vehicle'sinternal device control units and a second processing unit handlescommunications with the external network, and the only connectionbetween the two processing units is via a secure gateway. This gateway,which is preferably implemented by means of a gateway software componenton each of the two processing units, restricts the types ofcommunication which are possible across this connection or restrictswhich types of communications received by the first processing unit willbe passed on to the vehicle's device control units. This preventsunauthorised communications with device control units and controls whichoperations in the first processing unit can be triggered bycommunications from the second processing unit which were initiated fromelsewhere in the network.

In a preferred embodiment, a gateway software component running on thefirst processing unit holds a list of a predefined set of permittedmessages, and messages received at this first processing unit from thesecond processing unit are checked against the list and only thepermitted messages are passed on to the vehicle's device control units.Any other received messages are deleted (possibly with a failure reportbeing sent to the second processing unit for forwarding across thenetwork to whoever initiated the non-permitted communication).

The first processing unit is preferably running a static, real timeoperating system, such as an operating system implementing the OSEKstandard. OSEK is an abbreviation of a German term which translates as“Open systems and the corresponding interfaces for automotiveelectronics”, and was founded in 1993 as a joint project of the Germanautomotive industry aiming at an industry standard for an openarchitecture for distributed control units in vehicles. A staticoperating system can only perform specific predefined operations inresponse to predefined messages, these operations being fully defined atconfiguration time. Therefore, static operating systems are not capableof being modified by any software downloaded via the vehicle's networkconnections and there are no decisions to make at run time regarding howto process requests. This is advantageous since it ensures control ofthe types of operations which can be triggered by communications sent tothe first processing unit. Static operating systems can be limited tothe use of reliable, fully tested code such that there is a lowlikelihood of failures as well as prevention of interference bymalicious code and hacking.

A real time operating system is essential for the operation of certaintypes of applications affecting device control units, which theinvention preferably supports, such as an engine efficiency optimisationapplication which causes a control unit for the engine to make fineadjustments to the time which valves are open or an engine diagnosticsapplication which needs to complete a particular reading before a valveis opened.

The second processing unit is preferably running a security managerwhich handles authentication of requests received from the network. Anumber of authorised parties have predefined permissions which arespecific to them. The security manager on the second processing unitchecks whether a request is received from one of the authorised partiesand whether it matches their respective defined permissions beforepassing the request to its local gateway component for forwarding to thefirst processing unit.

Thus, the preferred embodiment of the invention provides a two-stagesecurity control. The first stage includes an authentication process andthen the second stage limits the operations which can be triggered byexternal communications so as to prevent any manipulation of software orhardware of the system which runs applications affecting the vehicle'ssafety-critical components. A hacker who successfully overcomes thechecking at the first stage (i.e. the security checks which arepreferably implemented at the second processing unit) is neverthelessprevented from manipulating any safety-sensitive vehicle components(which are connected to the first processing unit).

Furthermore, the invention inhibits downloaded code from monopolizingthe hardware resources or the vehicles internal communication buses.

The invention's separation of processing operations and control ofmessage flows between systems such that unauthorised operations cannotbe performed on the system which is connected to safety-critical devicecontrol units also has applications for the ‘networked-home’. Forexample, a user wishing to download entertainment software and programmecontent to their home computer needs to be able to prevent hacking intotheir home security system.

Thus, while the invention addresses a significant security problem fornetworked-vehicles, the invention is also clearly applicable to otherenvironments in which there are requirements both for communicationswith an external network and for protection of embedded data processingresources from unauthorised network access. With the increasingpervasiveness of embedded processing capabilities (within products suchas refrigerators, washing machines), and an increasing trend toproviding Internet access for products with embedded processing systems,the security benefits of the present invention are widely applicable.

The present invention is differentiated from known firewalls whichfilter which packets of data can be sent. The present invention enablesshielding from dangerous operations by checking requests after they havebeen sent to the data processing unit which connects to the vehicle'sinternal device control units' communication bus, and only permittingthe performance of a fixed set of operations. The invention thus goes astep further than filtering the messages which can be sent, by filteringrequest messages after they have been sent but prior to task execution.

BRIEF DESCRIPTION OF DRAWINGS

The invention will now be described in more detail, by way of exampleonly, with reference to the accompanying drawings in which:

FIG. 1 is a schematic representation of a vehicle's data processing andcommunications network according to a first embodiment of the invention,showing the separation of data processing units which communicate via asecure gateway; and

FIG. 2 shows the sequence of operations of processing of an operationrequest, sent from a remote data processing system, within a vehicleaccording to FIG. 1.

DESCRIPTION OF PREFERRED EMBODIMENT

As shown schematically in FIG. 1, a vehicle can be provided withcommunication and data processing resources which allow management ofand analysis of many devices within the vehicle. A first static,real-time operating system (RTOS) 10 runs on a first processing unit 20which is connected to the vehicle's internal communication bus 30 (forexample CAN, VAN). A number of real-time application programs 40 and afirst gateway software component 50 run on top of this operating system10. For example, the application programs 40 may include applicationsfor: air conditioning or heating control; engine efficiency optimisationand diagnostics; management of anti-lock braking system (ABS); window,seat and mirror movement; and control of main lights and indicatorlights. Each of these applications controls or obtains data from one ormore device control units 60 connected to the vehicle's internalcommunication bus 30 which connects to the first processing unit 20(hereafter referred to as ‘processing unit A’).

A second processing unit 70 (hereafter, ‘processing unit B’) isconnected to a graphic display apparatus 80, and via a communication bus90 to a GSM mobile telephone 100 providing the capability forcommunications with external networks 110, speakers 120 and a microphone130, and runs a second real time operating system 140. A Java VirtualMachine (JVM) 150 runs above this second operating system, and a numberof Java™ applications 160 use the services of the JVM. The Javaapplications may include applications for: in-vehicle entertainment;e-business including on-line business transactions; and SmartCardtransactions. A secure gateway software component 180 also runs in theJVM environment. There may also be non-Java applications 170 running onthe second operating system 140, for example a Navigation application.

Thus, the two operating systems are placed on different hardwareplatforms. The only connection between these hardware platforms, andhence the only link between the vehicle's internal device control units(such as an engine management unit) and the vehicle's communicationsresources which provide access to external networks, is a singleIP-based, serial communications link 190. The gateway softwarecomponents on the two hardware platforms exclusively controlcommunications across this link.

The Java gateway software component on processing unit B offers one ormore public methods that other programs must call in order to access theserial link. The serial link access code is implemented as private,native C code accessible only from within the gateway softwarecomponent. This can be represented in pseudo code as follows: publicclass Gateway { public int sendToVehicle (Message message, SecurityIDrequestor) { // First validate SecurityID ... // Check requestor isauthorised to send this particular Message // to vehicle StringformattedMessage, authorisedRequestor; ... // ConstructformattedMessage, authorisedRequestor int returnCode; returnCode =sendToSerial (formattedMessage, authorisedRequestor); return returnCode;} private native int sendToSerial (String fMsg, String aRqr); } Thegateway then implements the C code: int sendToSerial (JStringformattedMessage, JString authorisedRequestor) { // send message (andoptionally requestor) across serial link .. return successOrFailureCode;}

Thus, the native C code does the real message sending, and is onlyaccessible through the public sendToVehicle( ) method of the Gatewayclass. Java version 1.2 (also known as ‘Java2’) provides increasedlevels of built-in security (not shown in the pseudo-code) that permitsrestriction of a program's ability to invoke the sendToVehicle( ) methodat all, based on where the program originates.

As noted, the processing unit B which has connections to an externalnetwork runs a Java Security Manager. Referring to FIG. 2, when arequest 200 is received from outside the vehicle to change any data orcode, or to execute any code affecting one of the vehicle's internaldevice control units, the request has to pass two security barriers:

-   -   1. Firstly, the Java Security Manager on the externally        connected processing unit B performs authentication 220 (i.e.        determining whether the requester is an authorised party). The        authentication preferably uses standard public key cryptography        and digital signature verification. That is, a message is        decrypted using a stored public key and then a digital signature        (included in the request by the sender) is compared 230 with a        stored signature. A failure to match indicates tampering or        impersonation of an authorised party. If the authentication        fails, for example because of tampering, the request is rejected        240. This may be an explicit refusal or simple discarding of the        request.    -   If it passes authentication, the request is passed 250 to the        gateway component of processing unit B.    -   The gateway then checks 260 predefined authorised parties'        permissions, by checking an access control list to determine        whether this party (or this program code, downloaded from this        location—see later discussion of downloaded code) is permitted        to initiate the particular requested operation. The set of        requestable operations predefined in the access control lists        are completely standard operations, such that requesters can        only select an operation at run time and cannot modify any        operation (other than to specify operation parameter values from        a predefined range of parameter values in cases where there is a        need for the flexibility to specify parameter values).    -   2. If a request is determined 270 to be permitted by reference        to the access control lists, the gateway component on processing        unit B then sends 290 the request as a message to the gateway        component on processing unit A which is connected to the        vehicle's internal real-time network of device control units.    -   This receiving gateway component then checks 300 the message        content. If it is a recognised request, matching a list of        permitted operations held in ROM and configured in the static        operating system (typically an OSEK operating system in Europe)        of processing unit A, the request will be forwarded 330 to a        respective device control unit which is responsible for the        requested function. Note that this is a relatively simple lookup        operation. The device control unit then operates in the relevant        predefined way. All request messages which are not defined        during configuration of the static operating system of        processing unit A will be discarded, and so cannot disturb any        safety-critical functions on the vehicles internal bus. No        changes to this configuration are possible after the vehicle has        been manufactured.

In the static, real-time operating system all operations start with apredefined signal, run for a predefined time and then end in apredefined way (for example, an operation may be required to startwithin 12 instructions of the signal and complete within 20instructions). This gives behavioural certainty and improves safety,both because of the characteristic reliability and predictability ofstatic operating systems and because they are not tamperable. Alloperations which are not within the predefined set of permittedoperations can be prevented from being performed.

This two-stage security hurdle, and in particular limiting the messageswhich will be acted on at processing unit A to a predefined set ofmessages, achieves the high security requirements for vehicles' internalelectronic control systems.

The externally-connected processing unit B according to this embodimentof the invention is able to download executable code (for example, Javaapplets or ActiveX controls implementing engine diagnostic functions)from the Internet. Any such downloaded Java code is checked by themechanisms of the Java Security Manager running in processing unit B.Firstly, it is checked whether this code was downloaded from a trustedsource, such as by checking for a match with the vehicle manufacturer'sInternet address and performing digital signature analysis. The Javasecurity mechanisms on processing unit B can restrict the operationswhich can be performed by downloaded code (but see the later discussionof different versions of Java)—for example only triggering specificpredefined engine queries. Having passed these tests, operation requestsare sent to the gateway component on processing unit A.

While the network access to processing unit B provides some scope forhackers to try to overcome the security provision of the Java SecurityManager (or its equivalent), the second security barrier implemented atprocessing unit A further reduces risk to safety-critical operations onprocessing unit A and avoids exposure of confidential information ofdevices connected to this processing unit A. On receipt of a requestmessage at processing unit A, the request is compared with anunmodifiable list of permitted tasks which is stored at processing unitA as described above. If the requested task is one of the predefinedpermitted tasks, the request is passed on to the device control unitwhich is responsible for performing that task. If the requested task isnot listed, the request is discarded without being passed to any of thevehicle's device control units. A notification that the requested taskwill not be executed is preferably sent to the requester.

Thus, if a hacker overcomes the security checks performed at processingunit B and the hacker's unauthorized code generates a task request whichis sent to processing unit A, the strict limitation of operations whichcan be performed in response to such requests prevents any unauthorisedmanipulation of hardware or software on processing unit A. To executeany process on processing unit A in response to a remote request, one ofthe set of predefined permitted requests has to be sent via the gatewaycomponent and this causes a defined task to be executed in a definedway. No executable code can be passed to processing unit A.

The above discussion of the capabilities of the Java Security Managerassumes that the Java runtime environment includes a security manager ofsufficient strength. While this is true of Java 1.2, more limitedcapabilities are available in Java versions 1.1.X. For example, Java1.1.x allows for an incoming Applet to be signed, but does not providecertificate-based security as standard. In the case, the functions ofthe Java Security Manager can be supplemented by complementary programcode. Thus, not all versions of the Java Security Manager will performreliable authentication, but this can be implemented in separate programcode. It may also be impossible to rely on the Java Security Manager tocheck access control lists, although this is within the capabilities ofJava 1.2. The Java Security Manager is able to restrict method callsavailable to downloaded code for applets in Personal Java 1.x, BusinessJava 1.1.x, and any code in Java 1.2, but not for all embedded Javacode.

In an alternative embodiment of the invention, the user authenticationstep described above is performed at processing unit A rather than atthe externally-connected processing unit B. The request is then comparedwith an unmodifiable list of tasks which are permitted for theidentified user, this list being accessible at processing unit A. Thisalternative embodiment has greater protection from corruption andtherefore greater assurance that no tasks will be performed by users whoare not authorised to perform those tasks, but also has disadvantages asdescribed below.

In some embodiments of the invention, only the operating system of thefirst processing unit A will be a Real Time Operating System and in thiscase CPU cycles on processing unit A will be more valuable than onprocessing unit B such that it is desirable to minimize the processingwhich is performed on processing unit A. Secondly, it may be required touse only a small processor in processing unit A to keep costs down.These resource usage issues may be a sufficient justification forperforming the authentication of requesters and comparison of therequested operation with their personal list of permitted operations atprocessing unit B. It is worth noting that the performance of permittedtasks by unauthorised users does not present the same safety exposure asperformance of tasks which are not permitted for any user.

In another alternative embodiment of the invention, theexternal-network-connected gateway's checking of access control lists(which define what messages each user and each program is permitted tosend across the serial link to the vehicle's processing unit A) may bethe only check which is performed. If a request for an operation matchesthe user's or program's permitted operations, then the request is sentacross the link. Otherwise the request is rejected. The gateway onprocessing unit A can then simply pass on to the relevant device controlunits for execution any operation requests which reach it. This has theadvantage of minimizing the processing required on the RTOS firstprocessing unit, which can be important if the processing power of thisprocessing unit is sufficiently low that even simple checks cannot beperformed in real time, but it requires the access control list onprocessing unit B to be securely protected from hackers.

Most of the program code on the system other than Java and ActiveX codeis installed at system installation rather than being downloadeddynamically. If permitted at all, downloading and dynamic installationof native code is preferably restricted to code from the vehiclemanufacturer's own authorised network site. The standard securityfeatures are used to authenticate the manufacturer's site and to signthe downloaded code. This signing means that tampered code will beidentified and not installed on the vehicle. In this case, the only wayto overcome this security would be to install malicious code on themanufacturer's site and to sign it with their secret keys. This sort ofattack should be impossible for anyone other than the manufacturer's ownauthorised employees.

Native code on the network-connected side of the serial link cannoteasily access that link. The sendToSerial( ) method is not easilyaccessible (it would be given a secret name, with its API secret andhidden). Incoming native code would have to know the method's namestring in order to invoke the method. Without the name, incoming nativecode would have to find and access the serial link itself, and know howto find and configure the serial link, and know the protocol used acrossthis link to communicate with the internal processing unit A. In otherwords, requests to the processing unit A which do not come via theGateway would need to appear in every way as if they do, which is verydifficult to achieve. Other than by a long-running campaign of trial anderror (which should be detectable before it is successful), effecting asuccessful attack should be impossible without privileged access to theoriginal source code.

To really maximize security and prevent unauthorised requesters frominitiating operations affecting the vehicle's device control units,authentication and encryption could be used for the messages sentbetween the two Gateway components, but this would dramatically increasecosts because of the processor capabilities required to perform suchsecurity checks in real time.

A practical example use of the invention will now be described. considera car owner who detects that her car has been stolen. The owner contactsher Internet service provider (ISP) and authenticates herself (forexample, using a WAP telephone application such as is known in the art,or using confidential information which enables an operator toauthenticate her). The owner reports the car theft. The Internet serviceprovider and the car then perform mutual authentication via an exchangeof signed and encrypted messages (for example via SMS). The car informsthe ISP of its current and recent positions. The ISP informs the carthat it has been stolen and that re-starting of the car should beinhibited once turned off. An engine-restart-inhibition application onthe external-network-connected processing unit sends a message via thegateway requesting inhibition of restart. The ISP then contacts thepolice and provides position information. It will be recognised that inthis example there is a desire for an operation relating to an enginerestart control unit to be initiated from outside the car, and yet it isimportant that such an operation cannot be initiated by an unauthorisedparty and it is essential that this operation cannot be modified byhackers to switch off the engine while the car is in use.

As noted previously, alternative embodiments of the invention implementa physical separation of processing units and gateway processescontrolling communications between these units in environments otherthan vehicles, such as in a network-connected home which requiresoperations relating to protected resources to be invoked from elsewherein the network. For example, a home owner may wish a washing machinemanufacturer to be able to diagnose and service their washing machineand a security company to be able to monitor home security systems whilepreventing hackers from affecting the operation of the home securitysystem.

1-5. (canceled)
 6. A data processing apparatus, including: a first dataprocessing unit connected to one or more security-critical resources; asecond data processing unit connected to an external communicationsnetwork such that operation requests can be received from the externalnetwork; and a data communications link between the first and seconddata processing units; and a gateway component for controllingcommunications across the link, the gateway component limiting theoperations which can be performed at the first data processing unit inresponse to requests from the second processing unit to only apredefined set of permitted operations.
 7. A data processing apparatusaccording to claim 6, wherein the first and second data processing unitsand the link between them are implemented within a network-connectedhome environment, and the security-critical resources includesecurity-critical devices within the home which are managed byapplication programs running on the first data processing unit.
 8. Adata processing apparatus according to claim 6, wherein the externalnetwork is the Internet.
 9. A secure gateway computer program for anetwork-connected vehicle, comprising: a first gateway component forrunning on a first data processing unit connected to one or more devicecontrol units of the vehicle; and a second gateway component for runningon a second data processing unit connected to communications apparatusfor providing a wireless connection to an external network; wherein thefirst and second components of the secure gateway computer program areadapted to jointly control communications across a link between thefirst and second data processing units so as to limit the operationswhich can be performed at the first data processing unit in response torequests from the second processing unit to only a predefined set ofpermitted operations.
 10. A method for controlling the initiation ofoperations relating to secure resources on a first data processing unitsuch that only a limited predefined set of operations can be initiatedby requests from a second data processing unit connected to the firstdata processing unit by a communications link, the method comprising:storing a list of permitted operations which can be requested from thesecond data processing unit; comparing, by a secure gateway componentwhich controls communications across the communications link, requeststo perform operations relating to secure resources on the first dataprocessing unit with the list of permitted operations; and onlyexecuting the permitted operations.
 11. A method according to claim 10,implemented within a vehicle which includes the first and second dataprocessing units, wherein the secure resources include the vehicle'sinternal device control units.